services/src/main/java/org/keycloak/services/resources/admin/permissions/ClientPermissionsV2.java (1)

224-235: Scope matching can be simplified.

Arrays.asList(scope) creates a single-element list. The nested loop and expectedScopes.contains(s) can be replaced with a simple scope.equals(s) check. The same pattern appears in hasPermission(String) at lines 249-257 and could be simplified similarly.

♻️ Simplified scope matching

         Collection<Permission> permissions = root.evaluatePermission(new ResourcePermission(resource, resource.getScopes(), server), server);
-        List<String> expectedScopes = Arrays.asList(scope);
         for (Permission permission : permissions) {
             for (String s : permission.getScopes()) {
-                if (expectedScopes.contains(s)) {
+                if (scope.equals(s)) {
                     return true;
                 }
             }
         }

server-spi-private/src/main/java/org/keycloak/authorization/AdminPermissionsSchema.java (1)

304-326: Add CLIENTS resource type handling to getResourceName for consistent admin UI display.

The method currently has special display-name logic for USERS (resolving user model to return username), but lacks equivalent handling for CLIENTS. This causes client-scoped resources to display raw internal IDs instead of human-friendly client identifiers. The pattern already exists in the codebase (lines 91–95) and the required helper method resolveClient is available. Adding a CLIENTS branch that mirrors the USERS logic would ensure consistent and user-friendly resource display in the admin console.

Suggested addition after line 322

                return user.getUsername();
            }
+
+            if (CLIENTS.getType().equals(resourceType)) {
+                if (resource.getName().equals(CLIENTS_RESOURCE_TYPE)) {
+                    return "All clients";
+                }
+
+                ClientModel client = session.clients().getClientById(session.getContext().getRealm(), resource.getName());
+
+                if (client == null) {
+                    throw new ModelIllegalStateException("Client not found for resource [" + resource.getId() + "]");
+                }
+
+                return client.getClientId();
+            }
         }

tests/base/src/test/java/org/keycloak/tests/admin/authz/fgap/AbstractPermissionTest.java (3)

117-134: Returned UserPolicyRepresentation lacks server-assigned ID.

createUserPolicy returns the locally-constructed policy object rather than reading back the server response. The returned representation will not have its id field populated. Currently callers only use .getName(), so this works, but it is fragile — any future caller that needs the ID will silently get null.

Consider reading the created entity back from the response (e.g., via response.readEntity(...) or a follow-up findByName) or document this limitation clearly.

---

136-149: Same missing-ID concern applies to createClientPolicy.

Same pattern as createUserPolicy — the returned ClientPolicyRepresentation won't carry the server-assigned id.

---

151-179: createAllPermission is static but createPermission(client, resourceId, …) overloads are not.

Lines 151 and 163/167 follow the same pattern (build a ScopePermissionRepresentation, delegate to the static createPermission(ManagedClient, ScopePermissionRepresentation)), yet createAllPermission is static while the two createPermission overloads are instance methods. Making them all static (or all instance) would be more consistent.

Proposed fix

-    protected ScopePermissionRepresentation createPermission(ManagedClient client, String resourceId, String resourceType, Set<String> scopes, AbstractPolicyRepresentation... policies) {
+    protected static ScopePermissionRepresentation createPermission(ManagedClient client, String resourceId, String resourceType, Set<String> scopes, AbstractPolicyRepresentation... policies) {
         return createPermission(client, Logic.POSITIVE, resourceId, resourceType, scopes, policies);
     }

-    protected ScopePermissionRepresentation createPermission(ManagedClient client, Logic logic, String resourceId, String resourceType, Set<String> scopes, AbstractPolicyRepresentation... policies) {
+    protected static ScopePermissionRepresentation createPermission(ManagedClient client, Logic logic, String resourceId, String resourceType, Set<String> scopes, AbstractPolicyRepresentation... policies) {

tests/base/src/test/java/org/keycloak/tests/admin/authz/fgap/PermissionClientTest.java (1)

22-25: Mixing JUnit 4 and JUnit 5 assertion APIs.

Line 25 imports org.junit.Assert.fail (JUnit 4) while Line 40 imports org.junit.jupiter.api.Assertions (JUnit 5). The test class uses JUnit 5 annotations throughout. Prefer org.junit.jupiter.api.Assertions.fail consistently — the JUnit 4 fail has a different exception type (AssertionError vs JUnit 5's AssertionFailedError) and mixing frameworks can cause confusing test-runner behavior.

Proposed fix

-import static org.junit.Assert.fail;
+import static org.junit.jupiter.api.Assertions.fail;